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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (C) The Internet Society (1998). All Rights Reserved. 
Overview 
This document profiles Internet mail for voice messaging. It 


obsoletes RFC 1911 which describes version 1 of the profile. A list 
of changes from that document are noted in Appendix F. As well, 
Appendix A summarizes the protocol profiles of this version of VPIM. 


Please send comments on this document to the EMA VPIM Work Group 
mailing list: <vpim-lftema.org> 


Working Group Summary 


This profile is not the product of an IETF working group, though 
several have reviewed the document. It is instead the product of the 
VPIM Work Group of the Electronic Messaging Association (EMA). This 
work group, which has representatives from most major voice mail 
vendors and several email vendors, has held several interoperability 
demonstrations between voice messaging vendors and is currently 
promoting VPIM trials and deployment. 
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1. Abstract 


A class of special-purpose computers has evolved to provide voice 
messaging services. These machines generally interface to a 
telephone switch and provide call answering and voice messaging 
services. Traditionally, messages sent to a non-local machine are 
transported using analog networking protocols based on DTMF signaling 
and analog voice playback. As the demand for networking increases, 
there is a need for a standard high-quality digital protocol to 
connect these machines. The following document is a profile of the 
Internet standard MIME and ESMTP protocols for use as a digital voice 
messaging networking protocol. The profile is referred to as VPIM 
(Voice Profile for Internet Mail) in this document. 


This profile is based on earlier work in the Audio Message 
Interchange Specification (AMIS) group that defined a voice messaging 
protocol based on X.400 technology. This profile is intended to 
satisfy the user requirements statement from that earlier work with 
the industry standard ESMTP/MIME mail protocol infrastructures 
already used within corporate intranets. This second version of VPIM 
is based on implementation experience and obsoletes RFC 1911 which 
describes version 1 of the profile. 


2. Scope 


MIME is the Internet multipurpose, multimedia messaging standard. 
This document explicitly recognizes its capabilities and provides a 
mechanism for the exchange of various messaging technologies, 
primarily voice and facsimile. 


This document specifies a restricted profile of the Internet 
multimedia messaging protocols for use between voice processing 
server platforms. These platforms have historically been special- 
purpose computers and often do not have the same facilities normally 
associated with a traditional Internet Email-capable computer. As a 
result, VPIM also specifies additional functionality as it is needed. 
This profile is intended to specify the minimum common set of 
features to allow interworking between compliant systems. 


2.1 Voice Messaging System Limitations 


The following are typical limitations of voice messaging platform 
which were considered in creating this baseline profile. 


1) Text messages are not normally received and often cannot be 
easily displayed or viewed. They can often be processed only via 
text-to-speech or text-to-fax features not currently present in 
many of these machines. 


Vaudreuil & Parsons Standards Track [Page 3] 


RFC 2421 VPIM v2 September 1998 


2) Voice mail machines usually act as an integrated Message 
Transfer Agent, Message Store and User Agent. There is no relaying 
of messages, and RFC 822 header fields may have limited use in the 
context of the limited messaging features currently deployed. 


3) Voice mail message stores are generally not capable of 
preserving the full semantics of an Internet message. As such, use 
of a voice mail machine for gatewaying is not supported. In 
particular, storage of recipient lists, "Received" lines, and 
"Message-ID" may be limited. 


4) Internet-style distribution/exploder mailing lists are not 
typically supported. Voice mail machines often implement only 
local alias lists, with error-to-sender and reply-to-sender 
behavior. Reply-all capabilities using a CC list are not generally 
available. 


5) Error reports must be machine-parsable so that helpful responses 
can be voiced to users whose only access mechanism is a telephone. 


6) The voice mail systems generally limit address entry to 16 or 
fewer numeric characters, and normally do not support alphanumeric 
mailbox names. Alpha characters are not generally used for mailbox 
identification as they cannot be easily entered from a telephone 
terminal. 


2.2 Design Goals 


It is a goal of this profile to make as few restrictions and 
additions to the existing Internet mail protocols as possible while 
satisfying the requirements for interoperability with current 
generation voice messaging systems. This goal is motivated by the 
desire to increase the accessibility to digital messaging by enabling 
the use of proven existing networking software for rapid development. 


This specification is intended for use on a TCP/IP network; however, 
it is possible to use the SMTP protocol suite over other transport 
protocols. The necessary protocol parameters for such use is outside 
the scope of this document. 


This profile is intended to be robust enough to be used in an 
environment, such as the global Internet with installed-base gateways 
which do not understand MIME, though typical use is expected to be 
within corporate intranets. Full functionality, such as reliable 
error messages and binary transport, will require careful selection 
of gateways (e.g., via MX records) to be used as VPIM forwarding 
agents. Nothing in this document precludes use of general purpose 
MIME email packages to read and compose VPIM messages. While no 
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special configuration is required to receive VPIM compliant messages, 
some may be required to originate compliant structures. 


It is expected that a VPIM messaging system will be managed by a 
system administrator who can perform TCP/IP network configuration. 
When using facsimile or multiple voice encodings, it is suggested 
that the system administrator maintain a list of the capabilities of 
the networked mail machines to reduce the sending of undeliverable 
messages due to lack of feature support. Configuration, 
implementation and management of these directory listing capabilities 
are local matters. 


3. Protocol Restrictions 


This protocol does not limit the number of recipients per message. 
Where possible, server implementations should not restrict the number 
of recipients in a single message. It is recognized that no 
implementation supports unlimited recipients, and that the number of 
supported recipients may be quite low. 


This protocol does not limit the maximum message length. 
Implementers should understand that some machines will be unable to 
accept excessively long messages. A mechanism is defined in the RFC 
1425 SMTP service extensions to declare the maximum message size 
supported. 


The message size indicated in the ESMTP SIZE parameter is in bytes, 
not minutes or seconds. The number of bytes varies by voice encoding 
format and includes the MIME wrapper overhead. If the length must be 
known before sending, an approximate translation into minutes or 
seconds can be performed if the voice encoding is known. 


The following sections describe the restrictions and additions to 
Internet mail protocols that are required to be compliant with this 
VPIM v2 profile. Though various SMTP, ESMTP and MIME features are 
described here, the implementer is referred to the relevant RFCs for 
complete details. It is also advisable to check for IETF drafts of 
various Internet Mail specifications that are later than the most 
recent RFCs since, for example, MIME has yet to be published as a 
full IETF Standard. The table in Appendix A summarizes the protocol 
details of this profile. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [REO]. 
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4. 


Voice Message Interchange Format 


The voice message interchange format is a profile of the Internet 
Mail Protocol Suite. Any Internet Mail message containing the format 
defined in this section is referred to as a VPIM Message in this 
document. As a result, this document assumes an understanding of the 
Internet Mail specifications. Specifically, VPIM references 
components from the message format standard for Internet messages 
[RFC822], the Multipurpose Internet Message Extensions [MIME], the 
X.400 gateway specification [X.400], delivery status and message 
disposition notifications [REPORT] [DSN] [DRPT] [STATUS] [MDN], and the 
electronic business card [MIMEDIR] [VCARD]. 


4.1 Message Addressing Formats 


RFC 822 addresses are based on the domain name system. This naming 
system has two components: the local part, used for username or 
mailbox identification; and the host part, used for global machine 
identification. 


4.1.1 VPIM Addresses 


The local part of the address shall be a US-ASCII string uniquely 
identifying a mailbox on a destination system. For voice messaging, 
the local part is a printable string containing the mailbox ID of the 
originator or recipient. While alpha characters and long mailbox 
identifiers are permitted, most voice mail networks rely on numeric 
mailbox identifiers to retain compatibility with the limited 10 digit 
telephone keypad. As a result, some voice messaging systems may only 
be able to handle a numeric local part. The reception of 
alphanumeric local parts on these systems may result in the address 
being mapped to some locally unique (but confusing to the recipient) 
number or, in the worst case the address could be deleted making the 
message un-replyable. Additionally, it may be difficult to create 
messages on these systems with an alphanumeric local part without 
complex key sequences or some form of directory lookup (see 6). 


The use of the domain naming system should be transparent to the 
user. It is the responsibility of the voice mail machine to lookup 
the fully-qualified domain name (FODN) based on the address entered 
by the user (see 6). 


In the absence of a global directory, specification of the local part 
is expected to conform to international or private telephone 
numbering plans. It is likely that private numbering plans will 
prevail and these are left for local definition. However, it is 
RECOMMENDED that public telephone numbers be noted according to the 
international numbering plan described in [E.164]. The indication 
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that the local part is a public telephone number is given by a 
preceding ‘+’ (the ‘+’ would not be entered from a telephone keypad, 
it is added by the system as a flag). Since the primary information 
in the numeric scheme is contained by the digits, other character 
separators (e.g. ‘-') may be ignored (i.e. to allow parsing of the 
numeric local mailbox) or may be used to recognize distinct portions 
of the telephone number (e.g. country code). The specification of 
the local part of a VPIM address can be split into the four groups 
described below: 


1) mailbox number 
- for use as a private numbering plan (any number of digits) 
—- e.g. 2722@lucent.com 


2) mailbox number+extension 
- for use as a private numbering plan with extensions 
any number of digits, use of ‘+’ as separator 
- e.g. 2722+111@Lucent.com 


3) +international number 
- for international telephone numbers conforming to E.164 
maximum of 15 digits 
—- e.g. +16137637582@vm.nortel.ca 


4) - for international telephone numbers conforming to E.164 
maximum of 15 digits, with an extension (e.g. behind a 
PBX) that has a maximum of 15 digits. 
- e.g. +17035245550+230@ema.org 


Note that this address format is designed to be compatible with 
current usage within the voice messaging industry. It is not 
compatible with the addressing formats of RFCs 2303-2304. It is 
expected that as telephony services become more widespread on the 
Internet, these addressing formats will converge. 


4.1.2 Special Addresses 


Special addresses are provided for compatibility with the conventions 
of Internet mail. These addresses do not use numeric local 
addresses, both to conform to current Internet practice and to avoid 
conflict with existing numeric addressing plans. Two special 
addresses are RESERVED for use as follows: 


postmaster@domain 
By convention, a special mailbox named "postmaster" MUST exist on all 


systems. This address is used for diagnostics and should be checked 
regularly by the system manager. This mailbox is particularly likely 
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to receive text messages, which is not normal on a voice processing 
platform. The specific handling of these messages is an individual 
implementation choice. 


non-mail-user@domain 


If a reply to a message is not possible, such as a telephone 
answering message, then the special address "non-mail-user" must be 
used as the originator's address. Any text name such as "Telephone 
Answering", or the telephone number if it is available, is permitted. 
This special address is used as a token to indicate an unreachable 
originator. For compatibility with the installed base of mail user 
agents, implementations that generate this special address MUST send 
a negative delivery status notification (DSN) for reply messages sent 
to the undeliverable address. The status code for such NDN's is 
5.1.1 "Mailbox does not exist". 


Example: 
From: Telephone Answering <non-mail-user@mycompany.com> 
4.1.3 Distribution Lists 


There are many ways to handle distribution list (DL) expansions and 


none are ’standard’. Simple alias is a behavior closest to what most 
voice mail systems do today and what is to be used with VPIM 
messages. That is: 
Reply to the originator - (Address in the RFC822 Reply-to or From 
field) 
Errors to the submitter - (Address in the MAIL FROM: field of the 


ESMTP exchange and the Return-Path: 
RFC 822 field) 


Some proprietary voice messaging protocols include only the recipient 
of the particular copy in the envelope and include no "header fields" 
except date and per-message features. Most voice messaging systems 
do not provide for "Header Information" in their messaging queues and 
only include delivery information. As a result, recipient 
information MAY be in either the To or CC header fields. If all 
recipients cannot be presented (e.g. unknown DL expansion) then the 
recipient header fields MUST be omitted to indicate that an accurate 
list of recipients (e.g. for use with a reply-all capability) is not 
known. 
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4.2 Message Header Fields 


Internet messages contain a header information block. This header 
block contains information required to identify the sender, the list 
of recipients, the message send time, and other information intended 
for user presentation. Except for specialized gateway and mailing 
list cases, header fields do not indicate delivery options for the 
transport of messages. 


Distribution list processors are noted for modifying or adding to the 
header fields of messages that pass through them. VPIM systems MUST 
be able to accept and ignore header fields that are not defined here. 


The following header lines are permitted for use with VPIM voice 
messages: 


4.2.1 From 


The originator's fully-qualified domain address (a mailbox address 
followed by the fully-qualified domain name). The user listed in 
this field should be presented in the voice message envelope as the 
originator of the message. 


Systems compliant with this profile SHOULD provide the text personal 

name of the voice message originator in a quoted phrase, if the name 

is available. Text names of corporate or positional mailboxes MAY be 
provided as a simple string. From [RFC822] 


Example: 
From: "Joe S. User" <12145551212@mycompany.com> 
From: Technical Support <611@serviceprovider.com> 


The From address SHOULD be used for replies (see 4.6). However, if 
the From address contains <non-mail-user@domain>, the user SHOULD NOT 
be offered the option to reply, nor should notifications be sent to 
this address. 


Voice mail machines may not be able to support separate attributes 
for the FROM, REPLY-TO, and SENDER header field and the SMTP MAIL 
FROM command, VPIM conforming systems SHOULD set these values to the 
same address. Use of addresses different than those present in the 
From header field address may result in unanticipated behavior. 
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4.2.2 To 


The To header contains the recipient’s fully-qualified domain 
address. There may be one or more To: fields in any message. 


Example: 

To: +12145551213@mycompany.com 
Systems compliant to this profile SHOULD provide a list of recipients 
only if all recipients are provided. The To header MUST NOT be 


included in the message if the sending message transport agent (MTA) 
cannot resolve all the addresses in it, e.g. if an address is a DL 


alias for which the expansion is unknown (see 4.1.3). If present, 
the addresses in the To header MAY be used for a reply message to all 
recipients. 


Systems compliant to this profile MAY also discard the To addresses 
of incoming messages because of the inability to store the 
information. This would, of course, make a reply-to-all capability 
impossible. 


4.2.3 Cc 


The cc header contains additional recipients’ fully-qualified domain 
addresses. Many voice mail systems maintain only sufficient envelope 
information for message delivery and are not capable of storing or 
providing a complete list of recipients. 


Systems compliant to this profile SHOULD provide a list of recipients 
only if all disclosed recipients can be provided. The list of 
disclosed recipients does not include those sent via a blind copy. If 
not, systems SHOULD omit the To and Cc header fields to indicate that 
the full list of recipients is unknown. 

Example: 


Ce: +12145551213@mycompany.com 


Systems compliant to this profile MAY discard the Cc addresses of 


incoming messages as necessary. If a list of Cc or to addresses is 
present, these addresses MAY be used for a reply message to all 
recipients. 
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4.2.4 Date 


The Date header contains the date, time, and time zone in which the 
message was sent by the originator. The time zone SHOULD be 
represented in a four-digit time zone offset, such as -0500 for North 
American Eastern Standard Time. This may be supplemented by a time 
zone name in parentheses, e.g., "-0900 (PDT)". Compliant 
implementations SHOULD be able to convert RFC 822 date and time 
stamps into local time. 


Example: 
Date: Wed, 28 Jul 96 10:08:49 -0800 (PST) 


The sending system MUST report the time the message was sent. If the 
VPIM sender is relaying a message from a system which does not 
provide a time stamp, the time of arrival at the VPIM system SHOULD 
be used as the date. From [RFC822] 


4.2.5 Sender 


The Sender header field contains the actual address of the originator 
if the message is sent by an agent on behalf of the author indicated 
in the From: field. This header field MAY be sent by VPIM conforming 
system. If it is present in a VPIM message, the receiving VPIM 
implementation may ignore the field and only present the From header 
field. 


4.2.6 Return Path 


The Return-path header is added by the final delivering SMTP server. 
If present, it contains the address from the MAIL FROM parameter of 
the ESMTP exchange (see 5.1.2). Any error messages resulting from the 
delivery failure MUST be sent to this address (see [DRPT] for 
additional details). Note that if the Return-path is null ("<>"), 
e.g. no path, loop prevention or confidential, a notification MUST 
NOT be sent. If the Return path address is not available (either 
from this header or the MAIL FROM parameter) the From address may be 
used to deliver notifications. 


4.2.7 Message-id 
The Message-id header contains a unique per-message identifier. A 
unique message-id MUST be generated for each message sent from a 


compliant implementation. 


The message-id is not required to be stored on the receiving system. 
This identifier MAY be used for tracking, auditing, and returning 
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receipt notification reports. From [RFC822] 
Example: 
Message-id: <12345678@mycompany.com> 
4.2.8 Reply-To 


If present, the reply-to header provides a preferred address to which 
reply messages should be sent (see 4.6). Typically, voice mail 
systems can only support one originator of a message so it is 
unlikely that this field can be supported. A compliant system SHOULD 
NOT send a Reply-To header. However, if a reply-to header is present, 
a reply-to sender message MAY be sent to the address specified (that 
is, overwriting From). From [RFC822] This preferred address of the 
originator must also be provided in the originator’s vCard EMAIL 
attribute, if present (see 4.3.3). 


4.2.9 Received 


The Received header contains trace information added to the beginning 
of a RFC 822 message by MTAs. This is the only header permitted to 
be added by an MTA. Information in this header is useful for 
debugging when using an US-ASCII message reader or a header parsing 
tool. 


A compliant system MUST add Received header fields when acting as a 
gateway and MUST NOT remove any Received fields when relaying 
messages to other MTAs or gateways.. These header fields MAY be 
ignored or deleted when the message is received at the final 
destination. From [RFC822] 


4.2.10 MIME Version 


The MIME-Version header indicates that the message conforms to the 
MIME message format specification. Systems compliant with this 
specification SHOULD include a comment with the words "(Voice 2.0)". 
RFC 1911 defines an earlier version of this profile and uses the 
token (Voice 1.0). From [MIME1] [VPIM1] 


Example: 
MIME-Version: 1.0 (Voice 2.0) 


This identifier is intended for information only and SHOULD NOT be 
used to semantically identify the message as being a VPIM message. 
Instead, the presence of the content defined in [V-MSG] SHOULD be 
used if identification is necessary. 
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4.2.11 Content-Type 


The content-type header declares the type of content enclosed in the 
message. The typical top level content in a VPIM Message SHOULD be 
multipart/voice-message, a mechanism for bundling several components 
into a single identifiable voice message. The allowable contents are 
detailed in section 4.3 of this document. From [MIME2] 


4.2.12 Content-Transfer-Encoding 


Because Internet mail was initially specified to carry only 7-bit 
US-ASCII text, it may be necessary to encode voice and fax data into 
a representation suitable for that environment. The content- 
transfer-encoding header describes this transformation if it is 
needed. Compliant implementations MUST recognize and decode the 
standard encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted- 
Printable". The allowable content-transfer-encodings are specified 
in section 4.3. From [MIME1] 


4.2.13 Sensitivity 


The sensitivity header, if present, indicates the requested privacy 
level. The case-insensitive values "Personal" and "Private" are 
specified. If no privacy is requested, this field is omitted. 


If a sensitivity header is present in the message, a compliant system 
MUST prohibit the recipient from forwarding this message to any other 
user. A compliant system, however, SHOULD allow the responder to 
reply to a sensitive message, but SHOULD NOT include the original 
message content. The sensitivity of the reply message MAY be set by 
the responder. 


If the receiving system does not support privacy and the sensitivity 
is one of "Personal" or "Private", a negative delivery status 
notification must sent to the originator with the appropriate status 
code indicating that privacy could not be assured. The message 
contents SHOULD be returned to the sender to allow for a voice 
context with the notification. A non-delivery notification to a 
private message SHOULD NOT be tagged private since it will be sent to 
the originator. From: [X.400] 


4.2.14 Importance 
Indicates the requested importance to be given by the receiving 
system. The case-insensitive values "low", "normal" and "high" are 


specified. If no special importance is requested, this header may be 
omitted and the value assumed to be "normal". 
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Compliant implementations MAY use this header to indicate the 
importance of a message and may order messages in a recipient's 
mailbox. From: [X.400] 


4.2.15 Subject 


The subject field is often provided by email systems but is not 
widely supported on Voice Mail platforms. For compatibility with text 
based mailbox interfaces, a text subject field SHOULD be generated by 
a compliant implementation but MAY be discarded if present by a 
receiving system. From [RFC822] 


It is recommended that voice messaging systems that do not support 
any text user interfaces (e.g. access only by a telephone) insert a 
generic subject header of "VPIM Message" for the benefit of text 
enabled recipients. 


4.2.16 Disposition-Notification-To 
This header MAY be present to indicate that the sender is requesting 
a receipt notification from the receiving user agent. This message 
disposition notification (MDN) is typically sent by the user agent 
after the user has listened to the message and consented to an MDN 
being sent 
Example: 


Disposition-notification-to: +12145551213@mycompany.com 


The presence of a Disposition-notification-to header in a message is 


merely a request for an MDN described in 4.4.5. The recipients” user 
agents are always free to silently ignore such a request so this 
header does not burden any system that does not support it. From 
[MDN]. 


4.2.17 Disposition-Notification-Options 


This header MAY be present to define future extensions parameters for 
an MDN requested by the presence of the header in the previous 
section. Currently no parameters are defined by this document or by 
[MDN]. However, this header MUST be parsed if present, if MDNs are 
supported. If it contains a extension parameter that is required for 
proper MDN generation (noted with "=required"), then an MDN MUST NOT 
be sent if the parameter is not understood. See [MDN] for complete 
details. 
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Example: 


Disposition-notification-options: 
whizzbang=required, foo 


4.3 Voice Message Content Types 


MIME, introduced in [MIME1], is a general-purpose message body format 
that is extensible to carry a wide range of body parts. It provides 
for encoding binary data so that it can be transported over the 7-bit 
text-oriented SMTP protocol. This transport encoding (denoted by the 
Content-Transfer-Encoding header field) is in addition to the audio 
encoding required to generate a binary object. 


MIME defines two transport encoding mechanisms to transform binary 
data into a 7 bit representation, one designed for text-like data 
("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 
While Base64 is dramatically more efficient for audio data, either 
will work. Where binary transport is available, no transport 
encoding is needed, and the data can be labeled as "Binary". 


An implementation in compliance with this profile SHOULD send audio 
and/or facsimile data in binary form when binary message transport is 
available. When binary transport is not available, implementations 
MUST encode the audio and/or facsimile data as Base64. The detection 
and decoding of "Quoted-Printable", "bit", and "8bit" MUST be 
supported in order to meet MIME requirements and to preserve 
interoperability with the fullest range of possible devices. 

However, if a content is received in a transfer encoding that cannot 
be rendered to the user, an appropriate negative delivery status 
notification MUST be sent. 


The content types described in this section are identified for use 
within the multipart/voice-message content. This content, which is 
the fundamental part of a VPIM message, is referred to as a VPIM 
voice message in this document. 


Only the contents profiled subsequently can be sent within a VPIM 
voice message construct (i.e., the mulitpart/voice-message content 
type) to form a simple or a more complex structure (several examples 
are given in Appendix B). The presence of other contents within a 
VPIM voice message is an error condition and SHOULD result in a 
negative delivery status notification. When multiple contents are 
present within the multipart/voice-message, they SHOULD be presented 
to the user in the order that they appear in the message. 
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4.3.1 Multipart/Voice-Message 


This MIME multipart structure provides a mechanism for packaging a 
voice message into one container that is tagged as VPIM v2 compliant. 
The semantic of multipart/Voice-Message (defined in [V-MSG]) is 
identical to multipart/mixed and may be interpreted as that by 
systems that do not recognize this content-type. 


The Multipart/Voice-Message content-type MUST only contain the 
profiled media and content types specified in this section (i.e. 
audio/*, image/*, message/rfc822 and text/directory). The most 
common will be: spoken name, spoken subject, the message itself, 
attached fax and directory info. Forwarded messages are created by 
simply using the message/rfc822 construct. 


Conformant implementations MUST send the multipart/voice-message in a 
VPIM message. In most cases, this Multipart/Voice-Message content 
will be the top level (i.e. in the Content-Type header). Conformant 
implementations MUST recognize the Multipart/Voice-Message content 
(whether it is a top level content or below a multipart/mixed) and be 
able to separate the contents (e.g. spoken name or spoken subject). 


4.3.2 Message/RFC822 


MIME requires support of the Message/RFC822 message encapsulation 
body part. This body part is used within a multipart/voice-message 
to forward complete messages (see 4.5) or to reply with original 
content (see 4.6). From [MIME2] 


4.3.3 Text/Directory 


This content allows for the inclusion of a Versit vCard [VCARD] 


electronic business card within a VPIM message. The format is 
suitable as an interchange format between applications or systems, 
and is defined independent of the method used to transport it. It 


provides a useful mechanism to transport information about the 
originator that can be used by the receiving VPIM system (see 6) or 
other local applications 


Each vCard MUST be contained within a Text/Directory content type 
[MIMEDIR] within a VPIM message. [MIMEDIR] requires that the 
character set MUST be defined as a parameter value (typically us- 
ascii for VPIM) and that the profile SHOULD be defined (the value 
MUST be vCard within VPIM messages). 


Each VPIM message SHOULD be created with a Text/Directory (vCard 
profile) content type that MUST contain the preferred email address, 
telephone number, and text name of the message originator as well as 
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the vCard version. The vCard SHOULD contain the spoken name and role 
of the originator, as well as the revision date. Any other vCard 
attribute MAY also be present. The intent is that the vCard be used 
as the source of information to contact the originator (e.g., reply, 
call) .If the text/directory content-type is included in a VPIM 
message, the vCard profile [VCARD] MUST be used and MUST specify at 
least the following attributes: 


TEL = Public switched telephone number in international (E.164) 
format (various types, typically VOICE) 


EMAIL - email address (various types, typically INTERNET; the 
type VPIM is optionally used to denote an address that 
supports VPIM messages (see 18.1)) 


VERSION - Indicates the version of the vCard profile. Version 3.0 
[VCARD] MUST be used. 


The following attributes SHOULD be specified: 


N - Family Name, Given Name, Additional Names, Honorific 
Prefixes, and Suffixes. Because it is expected that 
recipients using a telephone user interface will use the 
information in the vCard to identify the originator, and 
the GUI will see the information presented in the FROM 
line, all present components in the text name of the FROM 
header field MUST match the values provided by the Vcard. 


ROLE - The role of the person identified in `N’ or ‘FN’, but may 
also be used to distinguish when the sender is a corporate 
or positional mailbox 


SOUND - spoken name sound data (various types, typically 32KADPCM) 
REV - Revision of vCard in ISO 8601 date format 


The vCard MAY use other attributes as defined in [VCARD] or 
extensions attributes not yet defined (e.g. capabilities). 


If present, the spoken name attribute MUST be denoted by a content ID 
pointing to an audio/* content elsewhere in the VPIM message. 


A typical VPIM message (i.e. no forwarded parts), MUST only contain 
one vCard -- more than one is an error condition. A VPIM message 
that contains forwarded messages, though, may contain multiple 
vCards. However, these vCards MUST be associated with the 
originator(s) of the forwarded message(s) and the originator of the 
forwarding message. As a result, all forwarded vCards will be 
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contained in message/rfc822 contents -- only the vCard of forwarding 
originator will be at the top-level. 


Example: 


Content-Type: text/directory; charset=us-ascii; profile=vCard 
Content-Transfer-Encoding: “bit 


BEGIN: VCARD 

N:Parsons;Glenn 

ORG:Northern Telecom 

TEL; TYPE=VOICE; MSG; WORK: +1-613-763-7582 

EMAIL; TYPE=INTERNET; glenn.parsons@nortel.ca 

EMAIL; TYPE=INTERNET; VPIM: 6137637582@vm.nortel.ca 
SOUND; TYPE=32KADPCM; ENCODING=URI: CID:<part1@VM2-4321> 
REV:19960831T1033102 

VERSION: 3.0 

END : VCARD 


4.3.4 Audio/32KADPCM 


An implementation compliant to this profile MUST send Audio/32KADPCM 
by default for voice [ADPCM]. Receivers MUST be able to accept and 
decode Audio/32KADPCM. Typically this body contains several minutes 
of message content, however if used for spoken name or subject the 
content should be considerably shorter (i.e. about 10 and 20 seconds 
respectively). 


If an implementation can only handle one voice body, then multiple 
voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be 
discarded. It is RECOMMENDED that this be done in the same order as 
they were sent. Note that if an Originator Spoken Name audio body and 
a vCard are both present in a VPIM message, the vCard SOUND attribute 
MUST point to this audio body (see 4.3.3). 


While any valid MIME body header MAY be used, several header fields 
have the following semantics when included with this body part: 


4.3.4.1 Content-Description: 
This field MAY be present to facilitate the text identification of 
these body parts in simple email readers. Any values may be used, 
though it may be useful to use values similar to those for Content- 
Disposition. 


Example: 


Content-Description: Big Telco Voice Message 
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4.3.4.2 Content-Disposition: 


This field MUST be present to allow the parsable identification of 
these body parts. This is especially useful if, as is typical, more 
than one Audio/32KADPCM body occurs within a single level (e.g. 
multipart/voice-message). Since a VPIM voice message is intended to 
be automatically played upon display of the message, in the order in 
which the audio contents occur, the audio contents must always be of 
type inline. However, it is still useful to include a filename 
value, so this should be present if this information is available. 
From [DISP] 


In order to distinguish between the various types of audio contents 
in a VPIM voice message a new disposition parameter "voice" is 
defined with the parameter values below to be used as appropriate 
(see 18.2): 


Voice-Message - the primary voice message, 

Voice-Message-Notification - a spoken delivery notification 
or spoken disposition notification, 

Originator-Spoken-Name - the spoken name of the originator, 

Recipient-Spoken-Name - the spoken name of the recipient if 
available to the originator and present if there is ONLY one 
recipient, 

Spoken-Subject- the spoken subject of the message, typically 
spoken by the originator 


Note that there SHOULD only be one instance of each of these types of 
audio contents per message level. Additional instances of a given 
type (i.e., parameter value) may occur within an attached forwarded 
voice message. 


Implementations that do not understand the "voice" parameter (or the 
Content-Disposition header) can safely ignore it, and will present 
the audio bodyparts in order (but will not be able to distinguish 
between them). 


Example: 


Content-Disposition: inline; voice=spoken-subject; 
filename="msg001.726" 


4.3.4.3 Content-Duration: 
This field MAY be present to allow the specification of the length of 


the audio bodypart in seconds. The use of this field on reception is 
a local implementation issue. From [DUR] 
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Example: 
Content-Duration: 33 
4.3.4.4 Content-Language: 


This field MAY be present to allow the specification of the spoken 
language of the audio bodypart. The encoding is defined in [LANG]. 
The use of this field on reception is a local implementation issue. 


Example for UK English: 
Content-Language: en-UK 
4.3.5 Image/Tiff 


A common image encoding for facsimile, known as TIFF-F, is a 
derivative of the Tag Image File Format (TIFF) and is described in 
several documents. For the purposes of VPIM, the F Profile of TIFF 
for Facsimile (TIFF-F) is defined in [TIFF-F] and the image/tiff MIME 
content type is defined in [TIFFREG]. While there are several 
formats of TIFF, only TIFF-F is profiled for use in a VPIM voice 
message. Further, since the TIFF-F file format is used in a store- 
and-forward mode with VPIM, the image MUST be encoded so that there 
is only one image strip per facsimile page. 


All VPIM implementations that support facsimile SHOULD generate 
TIFF-F compatible facsimile contents in the image/tiff; 
application=faxbw sub-type encoding by default. An implementation 
MAY send this fax content in VPIM voice messages and MUST be able to 
recognize and display it in received messages. If a fax message is 
received that cannot be rendered to the user (e.g. the receiving VPIM 
system does not support fax), then the system MUST return the message 
with a negative delivery status notification with a media not 
supported status code. 


While any valid MIME body header MAY be used (e.g., Content- 
Disposition to indicate the filename), none are specified to have 
special semantics for VPIM and MAY be ignored. Note that the content 
type parameter application=faxbw MUST be included in outbound 
messages. However, inbound messages with or without this parameter 
MUST be rendered to the user (if the rendering software encounters an 
error in the file format, some form of negative delivery status 
notification MUST be sent to the originator). 
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4.3.6 Proprietary Voice or Fax Formats 


Proprietary voice or fax encoding formats or other standard formats 
MAY be supported under this profile provided a unique identifier is 
registered with the IANA prior to use (see [MIME4]). The voice 
encodings should be registered as sub-types of Audio and the fax 
encodings should be registered as sub-types of Image 


Use of any other encoding except audio/32kadpcm or image/tiff; 
application=faxbw reduces interoperability in the absence of explicit 
manual system configuration. A compliant implementation MAY use any 
other encoding with explicit per-destination configuration. 


4.4 Other Message Content Types 


An implementation compliant with this profile MAY send additional 
contents in a VPIM message, but ONLY outside of the multipart/voice- 
message. The content types described in this section are identified 
for use with this profile. Additional contents not defined in this 
profile MUST NOT be used without prior explicit per-destination 
configuration. If an implementation receives a VPIM message that 
contains content types not specified in this profile, their handling 
is a local implementation issue (e.g. the unknown contents MAY be 
discarded if they cannot be presented to the recipient). Conversely, 
if an implementation receives a non-VPIM message (i.e., without a 
mulitpart/voice-message content type) with any of the contents 
defined in 4.3 & 4.4, it SHOULD deliver those contents, but the full 
message handling is a local issue (e.g. the unknown contents _or_ the 
entire message MAY be discarded). Implementations MUST issue 
negative delivery status notifications to the originator when any 
form of non-delivery to the recipient occurs. 


The multipart contents defined below MAY be sent as the top level of 
a VPIM message (with other noted contents below them as required.) As 
well, the multipart/mixed content SHOULD be used as the top level of 
a VPIM message to form a more complex structure (e.g., with 


additional content types). When multiple contents are present, they 
SHOULD be presented to the user in the order that they appear in the 
message. Several examples are given in Appendix B. 


4.4.1 Multipart/Mixed 


MIME provides the facilities for enclosing several body parts ina 
single message. Multipart/Mixed SHOULD only be used for sending 
complex voice or multimedia messages. That is, as the top level 
Content-Type when sending one of the following contents (in addition 
to the VPIM voice message) in a VPIM message. Compliant systems MUST 
accept multipart/mixed body parts. From [MIME2] 
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4.4.2 Text/Plain 


MIME requires support of the basic Text/Plain content type. This 
content type has limited applicability within the voice messaging 
environment. However, because VPIM is a MIME profile, MIME 
requirements should be met. Compliant VPIM implementations SHOULD 
NOT send the Text/Plain content-type. Compliant implementations MUST 
accept Text/Plain messages, however, specific handling is left as an 
implementation decision. From [MIME2] 


There are several mechanisms that can be used to support text (once 
accepted) on voice messaging systems including text-to-speech and 
text-to-fax conversions. If no rendering of the text is possible 
(i.e., it is not possible for the recipient to determine if the text 
is a critical part of the message), the entire message MUST be 
returned to the sender with a negative delivery status notification 
and a media-unsupported status code. 


4.4.3 Multipart/Report 


The Multipart/Report is used for enclosing human-readable and machine 
parsable notification (e.g. Message/delivery-status) body parts and 
any returned message content. The multipart/report content-type is 
used to deliver both delivery status reports indicating transport 
success or failure and message disposition notifications to indicate 
post-delivery events such as receipt notification. Compliant 
implementations MUST use the Multipart/Report construct. Compliant 
implementations MUST recognize and decode the Multipart/Report 
content type and its components in order to present the report to the 
user. From [REPORT] 


Multipart/Report messages from VPIM implementations SHOULD include 
the human-readable description of the error as a spoken audio/* 
content (this speech SHOULD also be made available to the 
notification recipient). As well, VPIM implementations MUST be able 
to handle (and MAY generate) Multipart/Report messages that encode 
the human-readable description of the error as text. Note that per 
[DSN] the human-readable part MUST always be present. 


4.4.4 Message/Delivery-status 


This MIME body part is used for sending machine-parsable delivery 
status notifications. Compliant implementations MUST use the 
Message/delivery-status construct when returning messages or sending 
warnings. Compliant implementations MUST recognize and decode the 
Message/delivery-status content type and present the reason for 
failure to the sender of the message. From [DSN] 
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4.4.5 Message/Disposition-notification 


This MIME body part is used for sending machine-parsable receipt 
notification message disposition notifications. Conforming 
implementations SHOULD use the Message/Disposition-notification 
construct when sending post-delivery message status notifications. 
These MDNs, however, MUST only be sent in response to the presence of 
the Disposition-notification-to header in 4.2.16. Conforming 
implementations should recognize and decode the Message/Disposition- 
notification content type and present the notification to the user. 
From [MDN] 


4.5 Forwarded Messages 


VPIM version 2 explicitly supports the forwarding of voice and fax 
content with voice or fax annotation. However, only the two 
constructs described below are acceptable in a VPIM message. Since 
only the first (i.e. message/rfc822) can be recognized as a forwarded 
message (or even multiple forwarded messages), it is RECOMMENDED that 
this construct be used whenever possible. 


Forwarded VPIM messages SHOULD be sent as a multipart/voice-message 
with the entire original message enclosed in a message/rfc822 content 
type and the annotation as a separate Audio/* or image/* body part. 
If the RFC822 header fields are not available for the forwarded 
content, simulated header fields with available information SHOULD be 
constructed to indicate the original sending timestamp, and the 
original sender as indicated in the "From" line. However, note that 
at least one of "From", "Subject", or "Date" MUST be present. As 
well, the message/rfc822 content MUST include at least the "MIME- 
Version", and "Content-Type" header fields. From [MIME2] 


In the event that forwarding information is lost through 
concatenation of the original message and the forwarding annotation, 
such as must be done in a gateway between VPIM and the AMIS voice 
messaging protocol, the entire audio content MAY be sent as a single 
Audio/* segment without including any forwarding semantics. 


4.6 Reply Messages 


Replies to VPIM messages (and Internet mail messages) are addressed 
to the address noted in the reply-to header (see 4.2.8) if it is 
present, else the From address (see 4.2.1) is used. The vCard EMAIL 
attribute, if present, SHOULD be the same as the reply-to address and 
may be the same as the From address. While the vCard is the senders 
preferred address it SHOULD NOT be used to generate a reply. Also, 
the Return-path address should not be used for replies. 
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Support of multiple originator header fields is often not possible on 
voice messaging systems, so it may be necessary to choose only one 
when gatewaying a VPIM message to another voice message system. 
However, implementers should note that this may make it impossible to 
send error messages and replies to their proper destinations. 


In some cases, a reply message is not possible, such as with a 
message created by telephone answering (i.e. classic voice mail). In 
this case, the From field MUST contain the special address non-mail- 
user@domain (see 4.1.2). A null ESMTP MAIL FROM address SHOULD also 
be used in this case (see 5.1.2). A receiving VPIM system SHOULD NOT 
offer the user the option to reply to this kind of message. 


4.7 Notification Messages 


VPIM delivery status notification messages (4.4.4) MUST be sent to 
the originator of the message when any form of non-delivery of the 
subject message or its components occurs. These error messages must 
be sent to the return path (4.2.6) if present, otherwise, the From 
(4.2.1) address may be used. 


VPIM Receipt Notification messages (4.4.5) should be sent to the 
sender specified in the Disposition-Notification-To header field 
(4.2.16), only after the message has been presented to the recipient 
or if the message has somehow been disposed of without being 
presented to the recipient (e.g. if it were deleted before playing 
itys 


VPIM Notification messages may be positive or negative, and can 
indicate delivery at the server or receipt by the client. However, 
the notification MUST be contained in a multipart/report container 
(4.4.3) and SHOULD contain a spoken error message. 


If a VPIM system receives a message with contents that are not 
understood (see 4.3 & 4.4), its handling is a local matter. A 
delivery status notification SHOULD be generated if the message could 
not be delivered because of unknown contents (e.g., on traditional 
voice processing systems). In some cases, the message may be 
delivered (with a positive DSN sent) to a mailbox before the 
determination of rendering can be made. 


5. Message Transport Protocol 


Messages are transported between voice mail machines using the 
Internet Extended Simple Mail Transfer Protocol (ESMTP). All 
information required for proper delivery of the message is included 
in the ESMTP dialog. This information, including the sender and 
recipient addresses, is commonly referred to as the message 
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"envelope". This information is equivalent to the message control 
block in many analog voice messaging protocols. 


ESMTP is a general-purpose messaging protocol, designed both to send 
mail and to allow terminal console messaging. Simple Mail Transport 
Protocol (SMTP) was originally created for the exchange of US-ASCII 
7-bit text messages. Binary and 8-bit text messages have 
traditionally been transported by encoding the messages into a 7-bit 
text-like form. [ESMTP] formalized an extension mechanism for SMTP, 
and subsequent RFCs have defined 8-bit text networking, command 
streaming, binary networking, and extensions to permit the 
declaration of message size for the efficient transmission of large 
messages such as multi-minute voice mail. 


The following sections list ESMTP commands, keywords, and parameters 
that are required and those that are optional for conformance to this 
profile. 


5.1 ESMTP Commands 
5.1.1 HELO 


Base SMTP greeting and identification of sender. This command is not 
to be sent by compliant systems unless the more-capable EHLO command 
is not accepted. It is included for compatibility with general SMTP 
implementations. Compliant servers MUST implement the HELO command 
for backward compatibility but clients SHOULD NOT send it unless EHLO 
is not supported. From [SMTP] 


5.1.2 MAIL FROM (REQUIRED) 


Originating mailbox. This address contains the mailbox to which 
errors should be sent. VPIM implementations SHOULD use the same 
address in the MAIL FROM command as is used in the From header field. 
This address is not necessarily the same as the message Sender listed 
in the message header fields if the message was received from a 
gateway or sent to an Internet-style mailing list. From [SMTP, ESMTP] 


The MAIL FROM address SHOULD be stored in the local message store for 
the purposes of generating a delivery status notification to the 
originator. The address indicated in the MAIL FROM command SHOULD be 
passed as a local system parameter or placed in a Return-Path: line 
inserted at the beginning of a VPIM message. From [HOSTREQ] 


Since delivery status notifications MUST be sent to the MAIL FROM 
address, the use of the null address ("<>") is often used to prevent 
looping of messages. This null address MAY be used to note that a 
particular message has no return path (e.g. a telephone answer 
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message). From [SMTP] 
52143 REPTL. TO 


Recipient’s mailbox. The parameter to this command contains only the 
address to which the message should be delivered for this 
transaction. It is the set of addresses in one or more RCPT TO 
commands that are used for mail routing. From [SMTP, ESMTP] 


Note: In the event that multiple transport connections to multiple 
destination machines are required for the same message, the set of 
addresses in a given transport connection may not match the list of 
recipients in the message header fields. 


5.1.4 DATA 


Initiates the transfer of message data. Support for this command is 
required. Compliant implementations MUST implement the SMTP DATA 
command for backwards compatibility. From [SMTP] 


5.1.5 TURN 


Requests a change-of-roles, that is, the client that opened the 
connection offers to assume the role of server for any mail the 
remote machine may wish to send. Because SMTP is not an 
authenticated protocol, the TURN command presents an opportunity to 
improperly fetch mail queued for another destination. Compliant 
implementations SHOULD NOT implement the TURN command. From [SMTP] 


Dok. 6 QUIT 


Requests that the connection be closed. If accepted, the remote 
machine will reset and close the connection. Compliant 
implementations MUST implement the QUIT command. From [SMTP] 


5.1.7 RSET 


Resets the connection to its initial state. Compliant 
implementations MUST implement the RSET command. From [SMTP] 


5.1.8 VRFY 


Requests verification that this node can reach the listed recipient. 
While this functionality is also included in the RCPT TO command, 
VRFY allows the query without beginning a mail transfer transaction. 
This command is useful for debugging and tracing problems. Compliant 
implementations MAY implement the VRFY command. From [SMTP] (Note 
that the implementation of VRFY may simplify the guessing of a 
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recipient’s mailbox or automated sweeps for valid mailbox addresses, 


resulting in a possible reduction in privacy. Various implementation 
techniques may be used to reduce the threat, such as limiting the 
number of queries per session.) From [SMTP] 

5.1.9 EHLO 


The enhanced mail greeting that enables a server to announce support 
for extended messaging options. The extended messaging modes are 
discussed in subsequent sections of this document. Compliant 
implementations MUST implement the ESMTP command and return the 
capabilities indicated later in this memo. From [ESMTP] 


Sat 10° BDAT 
The BDAT command provides a higher efficiency alternative to the 
earlier DATA command, especially for voice. The BDAT command provides 
for native binary transport of messages. Compliant implementations 


SHOULD support binary transport using the BDAT command [BINARY]. 


5.2 ESMTP Keywords 


The following ESMTP keywords indicate extended features useful for 
voice messaging. 


5.2.1 PIPELINING 


The "PIPELINING" keyword indicates ability of the receiving server to 
accept new commands before issuing a response to the previous 
command. Pipelining commands dramatically improves performance by 
reducing the number of round-trip packet exchanges and makes it 
possible to validate all recipient addresses in one operation. 
Compliant implementations SHOULD support the command pipelining 
indicated by this keyword. From [PIPE] 


5.2.2 SIZE 


The "SIZE" keyword provides a mechanism by which the SMTP server can 
indicate the maximum size message supported. Compliant servers MUST 
provide size extension to indicate the maximum size message that can 
be accepted. Clients SHOULD NOT send messages larger than the size 
indicated by the server. Clients SHOULD advertise SIZE= when sending 
messages to servers that indicate support for the SIZE extension. 
From [SIZE] 
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5.2.3 CHUNKING 


The "CHUNKING" keyword indicates that the receiver will support the 
high-performance binary transport mode. Note that CHUNKING can be 
used with any message format and does not imply support for binary 
encoded messages. Compliant implementations MAY support binary 
transport indicated by this capability. From [BINARY] 


5.2.4 BINARYMIME 


The "BINARYMIME" keyword indicates that the SMTP server can accept 
binary encoded MIME messages. Compliant implementations MAY support 
binary transport indicated by this capability. Note that support for 
this feature requires support of CHUNKING. From [BINARY] 


Duilio DSN 


The "DSN" keyword indicates that the SMTP server will accept explicit 
delivery status notification requests. Compliant implementations 
MUST support the delivery notification extensions in [DRPT]. 


5.2.6 ENHANCEDSTATUSCODES 


The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server 
augments its responses with the enhanced mail system status codes 
[CODES]. These codes can then be used to provide more informative 
explanations of error conditions, especially in the context of the 
delivery status notifications format defined in [DSN]. Compliant 
implementations SHOULD support this capability. From [STATUS] 


5.3 ESMTP Parameters - MAIL FROM 

5.3.1 BINARYMIME 
The current message is a binary encoded MIME messages. Compliant 
implementations SHOULD support binary transport indicated by this 


parameter. From [BINARY] 


5.3.2 RET 


The RET parameter indicates whether the content of the message should 
be returned. Compliant systems SHOULD honor a request for returned 
content. From [DRPT] 
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5.3.3 ENVID 


Dia 


4 


The ENVID keyword of the SMTP MAIL command is used to specify an 
"envelope identifier" to be transmitted along with the message and 
included in any DSNs issued for any of the recipients named in this 
SMTP transaction. The purpose of the envelope identifier is to allow 
the sender of a message to identify the transaction for which the DSN 
was issued. Compliant implementations MAY use this parameter. From 
[DRPT] 


ESMTP Parameters - RCPT TO 


5.4.1 NOTIFY 


The NOTIFY parameter indicates the conditions under which a delivery 
report should be sent. Compliant implementations MUST honor this 
request. From [DRPT] 


5.4.2 ORCPT 


The ORCPT keyword of the RCPT command is used to specify an 
"original" recipient address that corresponds to the actual recipient 
to which the message is to be delivered. If the ORCPT esmtp-keyword 
is used, it MUST have an associated esmtp-value, which consists of 
the original recipient address, encoded according to the rules below. 
Compliant implementations MAY use this parameter. From [DRPT] 


5.5 ESMTP - SMTP Downgrading 


The ESMTP extensions suggested or required for conformance to VPIM 
fall into two categories. The first category includes features which 
increase the efficiency of the transport system such as SIZE, 
BINARYMIME, and PIPELINING. In the event of a downgrade to a less 
functional transport system, these features can be dropped with no 
functional change to the sender or recipient. 


The second category of features are transport extensions in support 
of new functions. DSN and EnhancedStatusCodes provide essential 
improvements in the handling of delivery status notifications to 
bring email to the level of reliability expected of Voice Mail. To 
ensure a consistent level of service across an intranet or the global 
Internet, it is essential that VPIM compliant ESMTP support the ESMTP 
DSN extension at all hops between a VPIM originating system and the 
recipient system. In the situation where a ‘downgrade’ is unavoidable 
a relay hop may be forced (by the next hop) to forward a VPIM message 
without the ESMTP request for positive delivery status notification. 
It is RECOMMENDED that the downgrading system should continue to 
attempt to deliver the message, but MUST send an appropriate delivery 
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notification to the originator, e.g. the message left an ESMTP host 
and was sent (unreliably) via SMTP. 


6. Directory Address Resolution 


It is the responsibility of a VPIM system to provide the fully- 
qualified domain name (FODN) of the recipient based on the address 
entered by the user (if the entered address is not already a FODN). 
This would typically be an issue on systems that offered only a 
telephone user interface. The mapping of the dialed target number to 
a routeable FODN address allowing delivery to the destination system 
Can be accomplished through implementation-specific means. 


To facilitate a local dial-by-name cache, an implementation may wish 
to populate local directories with the first and last names, as well 
as the address information extracted from received messages. It is 
mandated that only address information from vCard attachments to VPIM 
messages be used to populate such a directory when the vCard is 
available. Addresses or names parsed from the header fields of VPIM 
messages SHOULD NOT be used to populate directories as it only 
provides partial data. Alternatively, bilateral agreements could be 
made to allow the bulk transfer of vCards between systems. 


7. IMAP 


The use of client/server desktop mailbox protocols like IMAP or POP 
to retrieve VPIM messages from a IMAP or POP message store is 
possible without any special modifications to this VPIM 
specification. Email clients (and web browsers) typically have a 
table for mapping from MIME type to displaying application. The 
audio/*, image/tiff and text/directory contents can be configured so 
that they invoke the correct player/recorder for rendering. In 
addition with IMAP clients, the first multipart/mixed content (if 
present) will not appear since it is a generic part. The user 
instead will be presented with a message that has (for example) audio 
and image contents. 


8. Management Protocols 
The Internet protocols provide a mechanism for the management of 
messaging systems, from the management of the physical network 


through the management of the message queues. SNMP should be 
supported on a compliant message machine. 
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8.1 Network Management 


The digital interface to the VM and the TCP/IP protocols MAY be 
managed. MIB II MAY be implemented to provide basic statistics and 
reporting of TCP and IP protocol performance [MIB II]. 


9. Conformance Requirements 


VPIM is a messaging application which must be supported in several 
environments and be supported on differing devices. These 
environments include traditional voice processing systems, desktop 
voice messaging systems, store and forward relays, and protocol 
translation gateways. 


In order to accommodate all environments, this document defines two 
areas of conformance: transport and content. 


Transport conformant systems will pass VPIM messages in a store and 
forward manner with assured delivery notifications and without the 


loss of information. It is expected that most store and forward 
Internet mail based messaging systems will be VPIM transport 
compliant. 


Content conformant systems will generate and interpret VPIM messages. 
Conformance in the generation of VPIM messages indicates that the 
restrictions of this profile are honored. Only contents specified in 
this profile or extensions agreed to by bilateral agreement may be 
sent. Conformance in the interpretation of VPIM messages indicates 
that all VPIM content types and constructs can be received; that all 
mandatory VPIM content types can be decoded and presented to the 
recipient in an appropriate manner; and that any unrenderable 
contents result in the appropriate notification. 


A summary of the compliance requirements is contained in Appendix A. 


VPIM end systems are expected to be both transport and content 
conformant. They should generate conforming content, reliably send 
it to the next hop system, receive a message, decode the message and 
present it to the user. Voice messaging systems and protocol 
conversion gateways are considered end systems. 


Relay systems are expected to be transport compliant in order to 
receive and send conforming messages. However, they must also create 
VPIM conforming delivery status notifications in the event of 
delivery problems. 
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Desktop Email clients that support VPIM and are expected to be 
content conformant. Desktop email clients use various protocols and 
API’s for exchanging messages with the local message store and 
message transport system. While these clients may benefit from VPIM 
transport capabilities, specific client-server requirements are out- 
of-scope for this document. 


10. Security Considerations 
10.1 General Directive 


This document is a profile of existing Internet mail protocols. To 
maintain interoperability with Internet mail, any security to be 
provided should be part of the of the Internet security 
infrastructure, rather than a new mechanism or some other mechanism 
outside of the Internet infrastructure. 


10.2 Threats and Problems 


Both Internet mail and voice messaging have their own set of threats 
and countermeasures. As such, this specification does not create any 
security issues not already existing in the profiled Internet mail 


and voice mail protocols themselves. This section attends only to 
the set of additional threats which ensue from integrating the two 
services. 


10.2.1 Spoofed sender 


The actual sender of the voice message might not be the same as that 
specified in the Sender or From header fields of the message content 
header fields or the MAIL FROM address from the SMTP envelope. Ina 
tightly constrained environment, sufficient physical and software 
controls may be able to ensure prevention of this problem. In 
addition, the recognition of the senders voice may provide confidence 
of the sender’s identity irrespective of that specified in Sender or 
From. It should be recognized that SMTP implementations do not 
provide inherent authentication of the senders of messages, nor are 
sites under obligation to provide such authentication. 


10.2.2 Unsolicited voice mail 


Assigning an Internet mail address to a voice mailbox opens the 
possibility of receiving unsolicited messages (either text or voice 
mail). Traditionally voice mail systems operated in closed 
environments and were not susceptible to unknown senders. Voice mail 
users have a higher expectation of mailbox privacy and may consider 
such messages as a security breach. Many Internet mail systems are 
choosing to block all messages from unknown sources in an attempt to 
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curb this problem. 
10.2.3 Message disclosure 


Users of voice messaging systems have an expectation of a level of 
message privacy which is higher than the level provided by Internet 
mail without security enhancements. This expectation of privacy by 
users SHOULD be preserved as much as possible. 


10.3 Security Techniques 


Sufficient physical and software control may be acceptable in 
constrained environments. Further, the profile specified in this 
document does not in any way preclude the use of any Internet object 
or channel security protocol to encrypt, authenticate, or non- 
repudiate the messages. 
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14. Appendix A - VPIM Requirements Summary 


The following table summarizes the profile of VPIM version 2 detailed 


in this document. Since in many cases it is not possible to simplify 
the qualifications for supporting each feature this appendix is 
informative. The reader is recommended to read the complete 


explanation of each feature in the referenced section. The text in 
the previous sections shall be deemed authoritative if any item in 
this table is ambiguous. 


The conformance table is separated into various columns: 


Feature - name of protocol feature (note that the indenting 
indicates a hierarchy of conformance, i.e. the 
conformance of a lower feature is only relevant if there 
is conformance to the higher feature) 


Section - reference section in main text of this document 
Area - conformance area to which each feature applies: 


C - content 
T - transport 


Status - whether the feature is mandatory, optional, or prohibited. 
The key words used in this table are to be interpreted as described 
in [REQ], though the following list gives a quick overview of the 
different degrees of feature conformance: 


Must - mandatory 

Should - required in the absence of a compelling 
need to omit. 

May - optional 

Should not - prohibited in the absence of a compelling 
need. 

Must not - prohibited 

Footnote - special comment about conformance for a particular 


feature 
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VPIM version 2 Conformance 


FEATURE 


Message Addressing Formats: 
Use DNS host names 
Use only numbers in mailbox IDs 
Use alpha-numeric mailbox IDs 
Support of postmaster@domain 
Support of non-mail-user@domain 
Support of distribution lists 


PPRPPP Pp 
WNNHEH 


Encoding outbound messages 

From 
Addition of text name 

To 
cc 
Date 
Sender 
Return-Path 
Message-id 
Reply-To 
Received 
MIME Version: 1.0 (Voice 2.0) 
Content-Type 
Content-Transfer-Encoding 
Sensitivity 
Importance 
Subject 
Disposition-notification-to 
Disposition-notification-options 
Other Headers 


hu 


x 


0 3004 UN RR 


NNNNNNNNNNNNNNNN DN DN NH 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
Message Header Fields: 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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FEATURE 


Detection & Decoding inbound messages 

From 

Present text personal name 
To 
ce 
Date 

Conversion of Date to local time 
Sender 
Return-Path 
Message ID 
Reply-To 
Received 
MIME Version: 1.0 (Voice 2.0) 
Content Type 
Content-Transfer-Encoding 
Sensitivity 
Importance 
Subject 
Disposition-notification-to 
Disposition-notification-options 
Other Headers 


x 


RHE PRP HR HE HP HHP HH SAH HHH HAHA 
NONNNNNNNNNNNNNNNNNDND NHN 


Message Content Encoding: 

Encoding outbound audio/fax contents 
7BIT 
8BIT 
Quoted Printable 
Base64 
Binary 

Detection £ decoding inbound messages 
7BIT 
8BIT 
Quoted Printable 
Base64 
Binary 


Be ds ds BD 
WWW WW WwW 


BPE PB BD 
WWW WW WwW 
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FEATURE 


SECTION 


Message Content Types: 
Inclusion in outbound messages 
Multipart /Voice—Message 
Message/RFC822 
Text/Directory 
include TEL, EMAIL, VERSION 
include ROLE, SOUND, N, REV 
only one voice type per level 
Audio/32KADPCM 
Content-Description 
Content-Disposition 
Content-Duration 
Content-Langauge 
Image/tiff; application=faxbw 
Audio/* or Image/* (other encodings) 
Multipart/Mixed 
Text/plain 
Multipart/Report 
human-readable part is voice 
human-readable part is text 
Message/delivery-status 
Message/disposition-notification 
Other contents 


SS UN E 


0H MW WWUN ROO BAB BWWWWNE 
x“ 


ee ee D 
ds ds PP ds ds ds BWW WWW WWW WWW y Ww 


Detection & decoding in inbound messages 
Multipart /Voice-Message 

Message/RFC822 

Text/Directory 
recognize TEL, EMAIL, VERSION 
recognize ROLE, SOUND, N, REV 

Audio/32KADPCM 
Content-Description 
Content-Disposition 
Content-Duration 
Content-Langauge 

Image/tiff; application=faxbw 
send NDN if unable to render 


x 


SS UN ER 


Hs ds ds ds ds ds ds ds ds ds ds ds 
WWWW WWW WWW Y Ww 
aor ds ds ds BWWWNE 
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Audio/* or Image/* (other encodings) |4.3.6 lel | |x| | | 
Multipart /Mixed [4.4.1 lex | | | | 
Text/plain 4.4.2 C|x 

send NDN if unable to render 4.4.2 C|x 


Vaudreuil & Parsons Standards Track [Page 41] 


RFC 2421 VPIM v2 September 1998 


FEATURE 


Multipart/Report 
human-readable part is voice 
human-readable part is text 
Message/delivery-status 
Message/disposition-notification 
Other contents 
send NDN if unable to render 


Oe WW uy 


BRE PBB PB AD 


Forwarded Messages 
use Message/RFC822 construct 
simulate headers if none available 


Reply Messages 
send to Reply-to, else From address 
do not send to non-mail-user 


Notifications 
use multipart/report format 
always send error on non-delivery 


| 
| 
| 
| 
| 

Message Transport Protocol: 

ESMTP Commands | 
| 
| 
| 
| 
| 
| 
| 


HELO 
MATL FROM 
support null address 

RCPT TO 
DATA 

TURN 

QUIT 

RSET 

VREY 

EHLO 

BDAT 


aaa a arar ar ar a 
PRPRPPRPPPPP EE 
FoOMAIAUTBAWNNE 
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Ld i. Me ES h 
| Clare 
O|M|o 
| |1 s| sul: 
| | | Jal [nfsle 
| Jalmjo| [o T|n 
| ¡rjolulm| | lo 
| lEls|[ila[w le 
A|T|D|Y[O|JO|t 
FEATURE bccn | | | | Be e 
ae KRG O LA ERTL OO ccc bl ll lod e Ca ia 
| Pa V S 
ESMTP Keywords & Parameters | | | | | | | 
PIPELINING (52:1 Ir] s| i 
SIZE [S22 [rixs a 
CHUNKING 5263 [7] | x | | 
BINARYMIME AA, eo pS LE x 
DSN 15.2.5 rx | | | | 
ENHANCEDSTATUSCODES |5.2.6 IT] ix | | | 
RET [54842 [Ti 2 es 
ENVID (5:38 ESA E 10] 
NOTIFY Eve E x | | 
ORCPT AZ T x 
| Pt} Ty td | 
ESMTP-SMTP Downgrading | IES a 1 
send delivery report upon downgrade | | | | | | | 
Directory Address Resolution | | | | | 
provide facility to resolve addresses 6 C x 
use vCards to populate local directory |6 lel |x| | | [8 
use headers to populate local directory i "| | | li | 
Management Protocols: | CS Fs Ks PA (| 
Network management ee | le! | 


Footnotes: 


1. MUST NOT include if all recipients are not known or resolvable. 

2. If a sensitive message is received by a system that does not 
support sensitivity, then it MUST be returned to the originator 
with an appropriate error notification. Also, a received 
sensitive message MUST NOT be forwarded to anyone. 

3. If the addtional header fields are not understood they MAY be 
ignored 

4. When binary transport is not available 

5. When binary transport is available 


Vaudreuil & Parsons Standards Track [Page 43] 


RFC 2421 VPIM v2 September 1998 


6. Other un-profiled contents must only be sent by bilateral 


agreement. 

7. If the content cannot be presented in some form, the entire 
message MUST be returned with a negative delivery status 
notification. 


8. When the vCard is present in a message 
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15. Appendix B - Example Voice Messages 


The following message is a full-featured message addressed to two 
recipients. The message includes the sender's spoken name and a short 
speech segment. The message is marked as important and private. 


To: +19725551212@vm1.mycompany.com 

To: +16135551234@VM1.mycompany.com 

From: "Parsons, Glenn" <12145551234@VM2 .mycompany.com> 

Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 

MIME-Version: 1.0 (Voice 2.0) 

Content-type: Multipart/Voice-Message; Version=2.0; 
Boundary="MessageBoundary" 

Content-Transfer-Encoding: “bit 

Message-ID: 123456789 VM2 .mycompany .com 

Sensitivity: Private 

Importance: High 


--MessageBoundary 

Content-type: Audio/32KADPCM 

Content-Transfer-Encoding: Base64 

Content-Disposition: inline; voice=0riginator-Spoken-Name 
Content-Language: en-US 

Content-ID: part1@VM2-4321 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is a sample of the base-64 Spoken Name data) 
fgdhgddlkgpokpeowrit09== 


—-MessageBoundary 

Content-type: Audio/32KADPCM 

Content-Transfer-Encoding: Base64 

Content-Description: Brand X Voice Message 

Content-Disposition: inline; voice=Voice-Message; filename=msgl.726 
Content-Duration: 25 


ilililjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOOJVFRERCESL/zqrq 
(This is a sample of the base64 message data) zb8tFdLTOt1PX]3 
u7wjOyRhws+krdns7R3ju0t 4tLF7CEOKOMxOTONRW/Pn30c8uHi 9== 


-—-MessageBoundary 
Content-type: text/directory; charset=us-ascii; profile=vCard 
Content-Transfer-Encoding: 7bit 


BEGIN: VCARD 

N:Parsons;Glenn;;Mr.; 

EMAIL; TYPE=INTERNET:+12145551234@VM2 .mycompany.com 
TEL: +1-217-555-1234 
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SOUND; TYPE=32KADPCM; ENCODING=URI: CID:<part1@VM2-4321> 
REV: 19951031T2227102 

VERSION: 3.0 

END : VCARD 


--MessageBoundary_ 


The following message is a forwarded single segment voice. Both the 
forwarded message and the forwarding message contain VCARDs with 
spoken names. 


To: +12145551212@vm1.mycompany.com 

From: "Vaudreuil, Greg" <+19725552345@VM2 .mycompany.com> 

Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 

MIME-Version: 1.0 (Voice 2.0) 

Content-type: Multipart/Voice-Message; Version=2.0; 
Boundary="MessageBoundary" 

Content-Transfer-Encoding: “bit 

Message-ID: ABCD-123456789@VM2.mycompany.com 


—-MessageBoundary 

Content-type: Audio/32KADPCM 

Content-Transfer-Encoding: Base64 

Content-Disposition: inline; voice=0riginator-Spoken-Name 
Content-Language: en-US 

Content-ID: part3@VM2-4321 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is a sample of the base-64 Spoken Name data) 
fgdhgd dlkgpokpeowrit09== 


—-MessageBoundary 

Content-type: Audio/32KADPCM 

Content-Description: Forwarded Message Annotation 
Content-Disposition: inline; voice=Voice-Message 
Content-Transfer-Encoding: Base64 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is the voiced introductory remarks encoded in base64) 
jrgoij3045itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gO5tkjpokfgw 
dlkgpokpeowrit09== 


--MessageBoundary 
Content-type: Message/RFC822 


Content-Transfer-Encoding: 7bit 


To: +19725552345@VM2 .mycompany.com 
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From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com> 

Date: Mon, 26 Aug 93 8:23:10 -0500 (EST) 

Content-type: Multipart/Voice-Message; Version=2.0; 
Boundary="MessageBoundary2" 

Content-Transfer-Encoding: “bit 

MIME-Version: 1.0 (Voice 2.0) 


—-MessageBoundary2 

Content-type: Audio/32KADPCM 

Content-Transfer-Encoding: Base64 

Content-Disposition: inline; voice=0riginator-Spoken-Name 
Content-Language: en-US 

Content-ID: part6@VM2-4321 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is a sample of the base-64 Spoken Name data) fgdhgd 
dlkgpokpeowrit09== 


—-MessageBoundary2 

Content-type: Audio/32KADPCM 
Content-Disposition: inline; voice=Voice-Message 
Content-Transfer-Encoding: Base64 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is the original message audio data) fgwersdfmniwrjj 
jrgoij3045itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gO5tkjpokfgw 
dlkgpokpeowrit09== 


—-MessageBoundary2 
Content-type: text/directory; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


BEGIN: VCARD 

N:Parsons;Glenn;W;Mr.; 

EMAIL; TYPE=INTERNET:+16135551234@VM2 .mycompany.com 
TEL: +1-613-555-1234 

SOUND; TYPE=32KADPCM; ENCODING=URI: CID:<part6@VM2-4321> 
REV:19951031T222710Z 

END: VCARD 


—-MessageBoundary2-— 
—-MessageBoundary 
Content-type: text/directory; charset=us-ascii 


Content-Transfer-Encoding: 7bit 


BEGIN: VCARD 
N: Vaudreuil; Greg; ;Mr.; 
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SOUND; TYPE=32KADPCM; ENCODING=URI: CID:<part3@VM2-4321> 
EMAIL; TYPE=INTERNET, VPIM:+19725552345@VM2 .mycompany.com 
TEL: +1-972-555-2345 

REV: 19951031T2227102 

VERSION: 3.0 

END : VCARD 


--MessageBoundary-- 


The following example is for a message returned to the sender by a 
VPIM gateway at VMl.company.com for a mailbox which does not exist. 


Date: Thu, 7 Jul 1994 17:16:05 -0400 

From: Mail Delivery Subsystem <MAILER-DAEMON@vm. company.com> 

Message-Id: <199407072116.RAA14128@vm1.company.com> 

Subject: Returned voice message 

To: 2175552345@VM2 .mycompany.com 

MIME-Version: 1.0 (Voice 2.0) 

Content-Type: multipart/report; report-type=delivery-status; 
boundary="RAA14128.773615765/VM1.COMPANY.COM" 


-—-RAA14128.773615765/VM1.COMPANY . COM 

Content-type: Audio/32KADPCM 

Content-Description: Spoken Delivery Status Notification 
Content-Disposition: inline; voice= Voice-Message-Notification 
Content-Transfer-Encoding: Base64 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 
(This is a voiced description of the error in base64) 
jrgoij3045itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgw 
dlkgpokpeowrit09== 


—-RAA14128.773615765/VM1.COMPANY.COM 
Content-type: message/delivery-status 


Reporting-MTA: dns; vml.company.com 


Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 
Action: failed 

Status: 5.1.1 (User does not exist) 

Diagnostic-Code: smtp; 550 Mailbox not found 
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 


-—-RAA14128.773615765/VM1.COMPANY.COM 
content-type: message/rfc822 


[original VPIM message goes here] 


Vaudreuil & Parsons Standards Track [Page 48] 


RFC 2421 VPIM v2 September 1998 


--RAA14128.773615765/VM1. COMPANY . COM-— 


The following example is for a receipt notification sent to the 
original sender for a message which has been played. This 
delivered VPIM message was received by a corporate gateway and 
relayed to a unified mailbox. 


Date: Thu, 7 Jul 1994 17:16:05 -0400 

From: "Greg Vaudreuil" <22722@vm.company.com> 

Message-Id: <199407072116.RAA14128@exchange.company.com> 

Subject: Voice message played 

To: 2175552345@VM2 .mycompany.com 

MIME-Version: 1.0 (Voice 2.0) 

Content-Type: multipart/report; 
Report-type=disposition-notification; 
Boundary="RAA14128.773615765/EXCHANGE . COMPANY . COM" 


--RAA14128.773615765/EXCHANGE . COMPANY . COM 

Content-type: Audio/32KADPCM 

Content-Description: Spoken Disposition Notification 
Content-Disposition: inline; voice= Voice-Message-Notification 
Content-Transfer-Encoding: Base64 
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 
(Voiced description of the disposition action in base64) 
jrgoij3045itj09fiuvdkjgWlakgQ93ijkpokfpgokOQ90gdffkjpokfgw 
dlkgpokpeowrit09== 


—-RAA14128.773615765/EXCHANGE.COMPANY.COM 
Content-type: message/disposition-notification 


Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) 
Original-Recipient: rfc822;22722@vm.company.com 

Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com 
Original-Message-ID: <199509192301.12345@vm2.mycompany.com > 


Disposition: manual-action/MDN-sent-automatically; displayed 


--RAA14128.773615765/EXCHANGE . COMPANY . COM 
Content-type: message/rfc822 


[original VPIM message goes here] 


--RAA14128.773615765/EXCHANGE . COMPANY . COM--— 
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16. Appendix C - Example Error Voice Processing Error Codes 


The following common voice processing errors and their corresponding 
status codes are given as examples. Text after the error codes are 
intended only for reference to describe the error code. 
Implementations should provide implementation specific informative 
comments after the error code rather than the text below. 


RFC 1893 Error codes 


Error condition 


Analog delivery failed 4.4.0 Persistent connection error 
because remote system is busy - other 
Analog delivery failed 4.4.1 Persistent protocol error 


because remote system is - no answer from host 


ring-no-answer 


Remote system did not answer 5.5.5 Permanent protocol error 
AMIS-Analog handshake ("D" in - wrong version 

response to "C" at connect 

time) 


Vaudreuil & Parsons 


Mailbox does not exist 


Mailbox full or over quota 


Disk full 


Command out of sequence 


Frame Error 


Mailbox does not support FAX 


Mailbox does not support TEXT 


Sender is not authorized 


Standards Track 


5.1.1 Permanent mailbox error 
- does not exist 


4.2.2 Persistent mailbox error 
<> fi. 


4.3.1 Persistent system error 
= Eutl 


5.5.1 Permanent protocol error 
- invalid command 


5.5.2 Permanent protocol error 
- syntax error 


5.6.1 Permanent media error 
- not supported 


5.6.1 Permanent media error 
- not supported 


5.7.1 Permanent security error 
- sender not authorized 
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Message marked private, but 5.3.3 Permanent system error 
system is not private capable - not feature capable 


17. Appendix D - Example Voice Processing Disposition Types 


The following common voice processing disposition conditions and 
their corresponding MDN Disposition (which contains the disposition 
mode, type and modifier, if applicable) are given as examples. 
Implementers should refer to [MDN] for a full description of the 
format of message disposition notifications. 


Notification event MDN Disposition mode, type € modifier 


Message played by recipient, manual-action/MDN-sent-automatically; 
receipt automatically returned displayed 


Message deleted from mailbox manual-action/MDN-sent-automatically; 
by user without listening deleted 

Message cleared when mailbox manual-action/MDN-sent-automatically; 
deleted by admin deleted/mailbox-terminated 


Message automatically deleted automatic-action/ 
when older than administrator MDN-sent-automatically; deleted/ 


set threshold expired 

Message processed, however manual-action/MDN-sent-automatically; 
audio encoding unknown - processed/error 

unable to play to user Error: unknown audio encoding 
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18. 


T8; 


18 


Appendix E - IANA Registrations 
1 vCard EMAIL Type Definition for VPIM 
To: ietf-mime-directory@imc.org 


Subject: Registration of new parameter for text/directory MIME type 
EMATL 


Type name: EMAIL 


Type purpose: To specify the electronic mail address for 
communication with the object the vCard represents (defined in 
[VCARD]). 


Type encoding: 8bit 
Type value: A single text value. 


Type special notes: The type may include the type parameter "TYPE" to 
specify the format or preference of the electronic mail address. The 
TYPE parameter values previously defined include: "internet" to 
indicate an Internet addressing type, "x400" to indicate a X.400 
addressing type and "pref" to indicate a preferred-use email address 
when more than one is specified. The value of "vpim" is defined to 
indicate that the address specified supports VPIM messages. Other 
IANA registered address type may also be specified. The default email 
type is "internet". A non-standard value may also be specified. 


Type example: 
EMAIL; TYPE=internet,vpim: jqpublic@xyz.doml.com 


.2 Voice Content-Disposition Parameter Definition 


To: IANA@IANA.ORG 


Subject: Registration of new Content-Disposition parameter 


Content-Disposition parameter name: voice 
Allowable values for this parameter: 


Voice-Message - the primary voice message, 

Voice-Message-Notification - a spoken delivery notification 
or spoken disposition notification, 

Originator-Spoken-Name - the spoken name of the originator, 


Vaudreuil & Parsons Standards Track [Page 52] 


RFC 2421 VPIM v2 September 1998 


Recipient-Spoken-Name - the spoken name of the recipient if 
available to the originator and present if there is ONLY one 
recipient, 

Spoken-Subject- the spoken subject of the message, typically 
spoken by the originator 


Description: 


In order to distinguish between the various types of audio contents 
in a VPIM voice message a new disposition parameter "voice" is 
defined with the preceding values to be used as appropriate. Note 
that there SHOULD only be one instance of each of these types of 
audio contents per message level. Additional instances of a given 
type (i.e., parameter value) may occur within an attached forwarded 
voice message. 
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19. Appendix F - Change History: RFC 1911 to this Document 


The updated profile in this document is based on the experience of a 
proof of concept demonstration of VPIM at EMA’96 in April 1996 anda 
subsequent demonstration of products at EMA’97 in April 1997. This 
version of the profile is significantly different from the previous 
described in [VPIM1]. The changes are categorized as general, 
content, transport and compliance. They are detailed below: 


1. General 


- All definitions are now contained in separate documents that are 
referenced by this profile. The new documents include: 


- a refined multipart/voice-message definition 


- a refined (i.e., added nibble order) audio/32KADPCM definition 


the definitions of TIFF-F and image/tiff for fax images 


- the Content-Duration definition 


Changed the Voice version to 2.0 


Added Table of Contents and more examples 
- Various editorial updates to improve readability 
- Added more security considerations 
2. Content 
- Modified multipart/voice-message content type by dropping the 
positional dependence of contents while restricting its contents to 


voice message specific content types 


- Explicitly indicated other contents that may be present ina 
multipart/mixed content type 


- Explicitly defined the forwarding model using message/RFC822 


- Explained the use of reply-to and from header fields for 
addressing message replies 


- Deprecated the special "loopback" address because of security 
concerns and its use only for testing 
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- Defined the non-mail-user reserved address to support the case in 
which replies to the originator are not possible 


- Eliminated the text name in the "To" and "CC" header fields. 
Deprecated ordering of text names in the "From" header. 


- Added support for facsimile using TIFF-F in an image/tiff; 
application=faxbw content type 


- Profiled vCard in the text/directory body part for transport of 
directory information about the originator 


- Loosened text restriction 
- Added additional details on delivery and receipt notifications 


- Added support for message disposition notifications, also known 
as receipt notifications. 


Added suggested addressing formats 


Described handling of private messages 


Described the handling of non-profiled contents in VPIM messages 


Described the use of Content-Disposition to semantically identify 
audio contents 


3. Transport 
- Moved binary support to optional 


- Added optional ESMTP keywords for return of content, enhanced 
status codes, original recipient, and envelope ID 


- Described use of null MAIL FROM address 
4. Compliance 


- Added an explicit section on conformance specifying conformance 
to content or transport 


- Improved conformance table in Appendix A 
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20. Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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